1. Field of the Invention
The present invention relates to a state machine. More specifically, the present invention discloses a state machine with a unique slot seizing state that is compatible with Personal Access Communications System (PACS) protocol enabled devices.
2. Description of the Prior Art
Please refer to FIG. 1. FIG. 1 is a partial functional diagram of Personal Access Communications System (PACS) architecture and signaling layers, which is fully described in the PACS Air Interface Rev. A manual, and which is incorporated herein by reference. A typical PACS wireless environment 10 includes one or more subscriber units (SUs) 12 in wireless communications with one or more radio ports (RPs) 14. The RPs 14, in turn, are in communications with a radio port controller unit (RPCU) 16, which controls the RPs 14, receiving signals from, and sending signals to, the RPs 14. The RPCU 16 is used to connect to a broader access network (not shown) such as a telephone network or the like. Interface A is an air interface, which is bridged by wireless signals between the SU 12 and the RP 14. Most modern communications protocols are arranged as a three-tiered structure, with the lowest layer, layer 1, being the physical layer that connects two devices. The layer 1 interface thus bridges interface A, extending only so far as the RP 14. Interface P provides connectivity between the RPCU 16 and the RPs 14, the exact nature of which may vary from implementation to implementation. There is a corresponding state machine on both the SU 14 and RPCU 16 sides for layer 2 communications, and the situation is similar for layer 3. Instead of layers 2 and 3, RP 14 plays the layer 1 role of bridging interfaces A and P.
Please refer to FIG. 2. FIG. 2 is a simplified block diagram of a PACS SU 20. The SU 20 includes a processor 22 that executes SU software modules 24. The software modules 24 include kernel code 26 that is implementation-specific, depending upon the hardware used within the SU 20; drivers 30 for providing a general interface with the kernel 26; a layer 1 interface 31; a layer 2 interface 32; a layer 3 interface 33; a man machine interface (MMI) 34 and utilities 35. The utilities 35 provide such functionality as timers and timer management, memory management, and the like. The MMI 34 is in charge of controlling an LCD 28, and handling input signals from a keypad 27, to provide a user interface for the SU 20. The PACS layer 3 interface 33 supports the MMI 34, and provides authentication, privacy (encryption/decryption), emergency calls and supplemental services. The PACS layer 2 interface 32 supports the layer 3 interface 33, and provides for alerting services, channel access, synchronization, multiplexing/demultiplexing, segmentation and assembly and the like. The PACS layer 1 interface 31 supports the layer 2 interface 32 and provides the physical link required to communicate with an RP 14, and hence the RPCU 16.
Please refer to FIG. 3. FIG. 3 is a block diagram for communications in a PACS system from a SU layer 3 perspective. Within a SU 40, a PACS layer 3 interface 43 is in communications with an MMI 44 for the SU 40, a PACS layer 2 interface 42, timers 41, and a PACS RPCU layer 3 interface 43x. Communications with the RPCU layer 3 interface 43x is wireless in nature, through the layer 2 interface 42, and a supporting layer 1 interface (not shown). However, from the standpoint of the SU layer 3 interface 43, such complications are not apparent, and the SU layer 3 interface 43 appears to communicate directly with the RPCU layer 3 interface 43x, both passing messages to, and receiving messages from, the RPCU layer 3 interface 43x. Similarly, the SU layer 3 interface 43 exchanges messages with the MMI 44 and the lower layer 2 interface 42. The layer 3 interface 43 is able to set a plurality of timers 41, and receive notification when any of the timers 41 expires.
Please refer to FIG. 4. FIG. 4 is a finite state model for a PACS layer 3 interface. For stable and predictable operations, a PACS layer 3 interface runs as a finite state machine 50S, transitioning from one state to another on an event, and performing some action just prior to the state transition. A key state is a null state 50 in which the layer 3 state machine 50S has no traffic channel established with an RPCU 16 and is awaiting anything xe2x80x9cinterestingxe2x80x9d to happen. Any xe2x80x9cinterestingxe2x80x9d event will cause the state machine 50S to transition out of the null state 50 and into another state designed to handle that particular xe2x80x9cinterestingxe2x80x9d event. For example, one such event is a layer 242 notification that the SU 40 must register with the RPCU 16. On such an event, the state machine 50S transitions to a terminal registration pending state 56 to await confirmation of registration with the RPCU 16. Two other types of events are incoming call detection and non-emergency call origination events. In the first, another user is attempting to call the SU 40. In the later, the MMI 44 indicates that the user is attempting to make a call. In either event, the state machine 50S first transitions to a radio call identifier pending state 51 to await reception from the RPCU layer 3 interface 43x of an identifier for the particular call. After receiving the radio call identifier from the RPCU layer 3 interface 43x, the state machine 50S transitions to either an incoming call present state 52, or a call initiated state 53 depending on whether or not the SU 40 is the originator of the call. In the incoming call present state 52, the state machine 50S waits for the user to answer the call, and alerts the user of an incoming call (i.e., by ringing the telephone). When the user answers the phone, the state machine 50S transitions into a call received state 57. In the call received state 57, the SU 40 informs the RPCU layer 3 interface 43x that the user has answered the phone, and awaits acknowledgement from the RPCU layer 3 interface 43x. Once the RPCU layer 3 interface 43x acknowledges the SU 40, the state machine 50S transitions into a stable state 59. Similarly, in the call initiated state 53, the state machine 50S awaits for connection confirmation from the RPCU layer 3 interface 43x that the call has been placed. Once such confirmation is received, the state machine 50S transitions into the stable state 59. It is in the stable state 59 that the exchange of user information (voice or data) occurs. Hanging up the phone, as indicated from the MMI 44, causes the state machine 50S to transition into a disconnect request state 54 in which the SU 40 inform the RPCU layer 3 interface 43x that the call is terminated and awaits acknowledgment of such from the RPCU layer 3 interface 43x. On such acknowledgment, the state machine 50S transitions back into the null state 50. Due to their nature, emergency calls are handled separately from normal, non-emergency calls. On detection of origination of an emergency call, the state machine 50S transitions from the null state 50 into an emergency call request state 58. While in the emergency call request state 58, the SU 40 awaits registration of the call with the RPCU layer 3 interface 43x, confirmation of which causes the state machine 50S to then transition into the call initiated state 53.
Every transition from the null state 50 requires that the SU 40 establish a traffic channel with the RPCU layer 3 interface 43x. This is termed slot seizing, and is required for any type of originating call, incoming calls, and terminal registration of the SU 40. However, the prior art does not distinctly provide for slot seizing. Slot seizing should not properly be performed in the null state 50 as the null state is specifically a state in which no traffic channel is established with the RPCU layer 3 interface 43x. Slot seizing must then be performed separately in each of the other states, such as in the terminal registration pending state 56, the radio call identifier pending state 51, and the emergency call request state 58. This makes these states unnecessarily complex, and further blurs the exact roles of these states. Software failure of the finite state machine 50S is made more probable, and determination of the exact cause of such a failure is made more complex.
It is therefore a primary objective of this invention to provide a slot seizing state for a PACS layer 3 finite state machine to provide a state machine with more distinctly defined states.
Briefly summarized, the preferred embodiment of the present invention discloses a finite state machine for a wireless device. The wireless device has a processor for executing program code to implement a plurality of states and to effect transitions between the states. The states include a null state for acting upon registration, call origination, and incoming call detection events; a slot seizing state for acting upon establishment of a traffic channel; a radio call identifier pending state for awaiting upon a radio call identifier; a terminal registration pending state for awaiting registration of the wireless device, and an emergency call request state for requesting emergency call services. The finite state machine transitions from the null state to the slot seizing state on any one of the registration, call origination, or incoming call detection events to effect establishment of the traffic channel, transitions from the slot seizing state to the radio call identifier pending state upon establishment of the traffic channel and any one of a non-emergency call origination event or the incoming call detection event, transitions from the slot seizing state to the terminal registration pending state upon establishment of the traffic channel and the registration event, and transitions from the slot seizing state to the emergency call request state upon establishment of the traffic channel and an emergency call origination event. When in the slot seizing state and upon expiration of a first timer, the finite state machine starts a second timer and then transitions to the null state, and when in the null state and upon expiration of the second timer, the finite state machine continues attempting registration until successful.
It is an advantage of the present invention that by providing the slot seizing state, the functionality of the finite state machine is more clearly defined. Ambiguities relating when and how slot seizing should be performed are removed. Programming implementation issues are thus made easier, enabling for more stable code.